home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17371 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
  4. Subject: Re: fastest code
  5. Date: 15 Apr 1996 09:01:27 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4ktrsnINNfb@keats.ugrad.cs.ubc.ca>
  8. References: <316112A2.7D37@public.sta.net.cn> <4kof6e$te@news1.mnsinc.com> <4krbhlINNbk4@keats.ugrad.cs.ubc.ca> <3171E8D2.41C67EA6@scn.de>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <3171E8D2.41C67EA6@scn.de>,
  12. Gerolf Wendland  <wendland%hpp015%hpp001.mch2.scn.de@scn.de> wrote:
  13. >Kazimir Kylheku wrote:
  14. >It was addition instead of multiplication by constant values (i+i instead of 2*i)
  15. >
  16. >> If I were writing a compiler, I wouldn't bother ``optimizing'' this case at
  17. >> all: If the programmer thinks he knows better, let him have his addition!
  18. >
  19. >Let the programmer write down his way of solving the problem.
  20. >Let the compiler try to do the tideous optimization as much as possible.
  21.  
  22. In this case, the programmer is clearly trying to second-guess the compiler's
  23. optimization. Why else would anyone write i+i nowadays? Maybe the programmer
  24. really _does_ know better. Hey may be privy to some information about the
  25. architecture at hand that the compiler writers did not know, and the addition
  26. may in fact produce faster code.
  27.  
  28. Remember, the compiler would have to find a faster way to do it than using the
  29. addition in order for the optimization to be justified. There may be a
  30. machine-specific peephole optimization for this, but a compiler with a general
  31. front end which performs machine independent optimizations on an intermediate
  32. represention might have no reason at all to want to optimize a simple addition.
  33. To do that, it would have to pick a faster operation. On a machine-independent
  34. strength reduction scale, a shift and an add are roughly equal. There is no
  35. reason to choose one over the other.
  36.  
  37. Within an architecture family there may be wide variations in what is fast
  38. code. I've seen hand-written assembly for an old Sparc model perform poorly
  39. compared to compiled C, probably because the code was compiled to take
  40. advantage of the new model's pipeline setup.  For an example, all you need is
  41. to run the GNU fcrypt() test on a SuperSparc or UltraSparc, and compare the
  42. performance with the assembly code linked in to the pure C program.
  43.  
  44. Suppose I have an older compiler that cannot take advantage of my latest
  45. binary-compatible CPU. If it second-guesses what I'm doing, it can produce
  46. slower code than if it tries to translate some of my idioms more literally.
  47.  
  48. Maybe the newer CPU has multiple units for doing additions, but only one
  49. of them does shifting, and the programmer knows that...
  50.  
  51. -- 
  52. I'm not really a jerk, but I play one on Usenet.
  53.